COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	\\M1BASL30\M2BASI30\M3BASB30\M4NGR30
C00015 ENDMK
C⊗;
\\M1BASL30;\M2BASI30;\M3BASB30;\M4NGR30;
\F1\CJan 25,1981



InfoWorld
530 Lytton Ave.
Palo Alto, CA, 94301


Dear InfoWorld:

\J
This is a response to the Jonathan Sach/Steve Gadol 
review of TLC-LISP in your January
19, 1981 issue. My initial reaction was one of dismay. I had sent a review
copy to your offices (as requested) over six months ago; and here was an incomplete
and inaccurate review, not just of TLC, but of LISP itself.

I decided that someone else should or would respond, but then, since even the 
ZIP code was wrong, something should be done soon. So what follows is my review
of your review. I hope you will publish it in a timely fashion, giving it
coverage comparable to the initial review.
\.


\C\F3Inaccuracies about LISP\F1
\J
1. The first three paragraphs of the review defy classification. Largely
they're inaccurate, but I don't really understand what they mean.

2. The fourth paragraph is definitely incorrect. LISP was \F2not\F1
designed for researchers in mathematical logic, and until the last
few years I doubt that you'd find a logician who would  
be interested in looking at LISP.

3. The  discussion about PROG is dismaying for several reasons. First,
if nothing else, structured programming rhetoric 
and methodolody should have convinced
the world that things like 1960 LISP's PROG-label-GO-RETURN should be 
viewed suspiciously.
Second, the suggested LET-PROGN combination is  vacuous in attempting
to replace PROG-constructs.
LET is a sugar-coated version of LAMBDA; and PROGN is a sugar-coated version of
left-to-right evaluation, both features nicely contained within the 
applicative subset called "pure LISP".
\.

\C(LET ((x1 v1) ... (xn vn)) exp)  \F4≡\F1 ((LAMBDA (x1 ... xn) exp) v1 ... vn)

\C(PROGN e1 e2  ... en) \F4≡\F1  ((LAMBDA (d1 d2 ... dn) dn) e1 e2 ... en)

\J
In fact, the  advertised use of LET to simulate PROG variables
is not necessary in modern LISPs. AUX-variables in the formal parameter list
handle that much better. Furthermore,
 in many LISPs  PROGN  is implied in the body of constructs
and is only needed when the default sequencing is to be over-ridden.

So LET and PROGN, actually add nothing new. What \F2is\F1 the purpose of the PROG
assortment? A moment's analysis will reveal that
PROG is used for control structuring: iteration and exception handling
are the two major uses. The modern LISPs offer both: a DO-construct
that packages up the idea of initialization, iteration, and testing; and
a CATCH-THROW pair (a generalization of the ancient LISP ERRSET-ERR pair)
to expedite the construction of exception handlers.  Indeed, with these
control constructs one can build all the generality of PROGs.

However,  just like the card reader, it's time to let go of PROG-like features
for everyday programming, and certainly
when introducing new people to LISP. 
The PROG collection was intentionally omitted (as
was card I-O), and  modern constructs were substituted.
\.


\C\F3Inaccuracies about TLC-LISP\F1
\J
1. TLC-LISP is better described as a subset of LISP machine LISP (1980's), not
its parent MACLISP (1970's)

2. TLC-LISP has the AUX-variables, DO, CATCH, and THROW mentioned above.

3. TLC-LISP is stated to "compile" its programs; it does not, it
interprets its programs. I have an
experimental compiler, but it is not released.

4. TLC-LISP does not use 16-bit arithmetic; it uses
\F214-bit\F1 arithmetic. This is a temporary expedient to 
gain efficiency in LISP integer arithmetic. The long-term solution
is arbitrary-precision arithmetic operations. This is a well-known 
technique, introduced into  LISP 1.6 in 1966, and exists 
even in some micro-LISPs. Rather than  develop another integer package,
we opted to supply  floating-point  arithmetic. Unfortunately,
the reviewer seems unaware of
 the floating-point package.

5. The discussion of program size is  quite muddled. The
TLC-LISP interpreter does \F2not\F1
occupy 30K, it occupies about 20K. Though the disk image is 30K, the system
is read into memory, moves the code segment up below
CP/M, and then builds the initial object-list. Allowing for CP/M,
this leaves about 20K, not 10K, on a 48K machine; 32K \F2Bytes\F1
are available on a 64K machine. Converting bytes to objects --a cons-object
is four bytes--, says that 
a 64K machine is about comparable with a 7090 for space.
Until 1966,
the 7090 was the home of most LISP and AI research.
A Z-80 is significantly faster than a 7090  --TLC-LISP executes about
1/3  the speed of MACLISP running on a KA-10. 

6. In "expanded version ...to 32K for data" 
implies \F2bytes\F1 but acutally refers to \F2objects\F1 not \F2bytes\F1 
This version uses bank-switching to support up to four banks
--128K bytes-- for LISP objects
with other banks for non-LISP data and programs. This
scheme supplies TLC-LISP with the
space of a mid-sized PDP-10 LISP job  without
noticeable speed degradation. This version was running
at the AAAI Conference last summer, and has been released to a few sites.

7. The docmentation: it is \F2not\F1 meant to be a tutorial; I guess it 
succeeded at that. It also got low marks in the "bar chart"; I guess the 
inability of the reviewers to 
discover  TLC-LISP's features reinforces that too.

8. "On error handling", TLC-LISP calls a function named ERROR when an
anomaly occurs. To define your own handler, redefine the function ERROR.
It seems to work for me and my other customers.
\.


\C\F3Incompleteness of review\F1
\J
1. This is one of the most objectional areas. The disk was supplied
free of charge over six months ago, yet a superficial review resulted.
Even the TLC "flyer" mentions generalized
parameter passing (&AUX, &OPTIONAL, and &REST),
CATCH, THROW, DO, property-lists, floating-point, read macros,
run-time macros, generalized I/O, and virtualized functions.
A cursory glance through the index of the "fair"
documentation  could have revealed much. Even a letter or two
could have been transmitted to me in six-months. Bad marks here, folks.
\.


\C\F3Petty annoyances.\F1
\J
1. (TLC) is (T .(L . C)) --a LISP person should know the difference.

2. Misspellings and typographical errors: the most obnoxious one is the
Zip code! its not 59044, 95044 please.

3. I quote: "equally dismal is the limit of 255 characters in the string length".
Oh, come on!  I'd like to see
the application that the reviewer has in mind.

4. Though not J. Sach's fault, the price reported is not correct. I had considered
raising the price to $250/$20, but decided to leave it at $150/$15. There is no 
way to make a living  at either price; at $150 it's a "public service".

5. I agree, it is difficult to catch me.
I do have an answering machine installed for my customers;
in fact, installed in mid-August.
\.


\C\F3LISP-related Events\F1
\J
Three projects underway may interest InfoWorld readers:
At the West Coast Computer Faire this spring, a group of us have organized
a special session on LISP and object-oriented languages. I will be presenting
a tutorial  and demos that will dispell some of the myths and misconceptions 
about LISP-related activities.

Also, this summer Larry Masinter of Xerox PARC, and I
 will give an intensive one-week  LISP course at the 
Western Institute in Computer Science hosted by the University of Santa
Clara.

To InfoWorld in general: I would suggest that if you'd  send me a free 
subscription,
I'd be glad to write reviews of some of \F2your\F1 material...like the
piece about computer literacy and automatic programming
--\F2The Mass Market Micro\F1. Things like that really
should be answered.
\.
\←L\→S\←R\-L\/'2;\+L\→L

Yours sincerely,


John R. Allen
The LISP Company
POB 487
Redwood Estates CA, 95044

\←S\→L
cc: S. Gadol
    J. Sachs